Organizations involved in software development typically employ a source code control (SCC) system for managing source code assets being produced by software developers. These systems provide three principle benefits to these organizations:                1. They serve as a central repository for storing and securing electronic assets being created in an organization.        2. They retain historical information regarding how electronic assets have evolved over time and provide access to historical versions of these assets.        3. They provide a mechanism for individual developers to share their work with other team members.        
In the course of using the system for the third listed benefit, individual contributors generally work with one or more files in a private workspace to achieve the objective of their current task. When that objective is met, modifications are submitted to the SCC system whereby they are made available to other team members. It is common practice for individuals to not submit their work to the SCC system until it has reached a level of stability that makes it suitable for other team members to consume. Until that time, their work remains in a private workspace that does not influence the work of other team members.
As long as this work remains in a private workspace, however, it generally does not benefit from any of the aforementioned benefits of SCC systems. Still, there are many situations where developers may desire these benefits without assuming the risk of submitting unfinished work for common consumption by the team. Several such situations are as follows:                1. Developers may need to halt work-in-progress to assume a higher priority task. In such a case, it is desirable to restore unmodified versions of files to the private workspace while archiving the current set of modifications in a manner that can be restored at a later time.        2. Developers may desire to use the SCC system to create a backup of current work in progress in the event that a system failure causes changes in the private workspace to be lost.        3. Developers may desire to checkpoint current work in progress that has reached a notable level of stability yet is still not ready for consumption by the rest of the team.        4. There may be a need to share work in progress with a team member who is willing to assume the higher level of risk associated with consuming the work in a non-final state.        5. There may be a need to transfer work in progress to another team member who is taking over the work objective from the current developer.        6. There may be a need to transfer work in progress to another private workspace where it will be more convenient to continue the work.        
Current SCC systems can accomplish some of these goals through the parallel development mechanisms associated with branching. Branching, however, is a complicated process that greatly increases the amount of work for both users and administrators. This work involves the process of setting up new branches for the execution of all work as well as the process of merging completed work from the new branch to an integration branch where it becomes available for general consumption. For developers, this work is superfluous to their stated goal of creating new software. Branching also has the drawback of complicating the structure of the SCC repository and over time makes it significantly more difficult to work with.